Hridaya uses a single YAML configuration file (config.yaml) to define all tracking behavior, rate limits, and API endpoints. The system validates your configuration at startup to ensure feasibility before making any API requests.
The system calculates total request load and validates against rate limits:
# For each item, calculate requests per windowreqs_per_window = window_seconds // polling_interval_in_seconds# Sum across all itemstotal_requests = sum(reqs_per_window for all items)# Must satisfy: total_requests <= REQUESTS
Example Calculation:With REQUESTS: 15 and WINDOW_SECONDS: 60:
Item 1: 60s / 8s = 7.5 req/window
Item 2: 60s / 60s = 1 req/window
Item 3: 60s / 30s = 2 req/window
Item 4: 60s / 60s = 1 req/window
Total: 11.5 requests per 60s ✓ (within limit of 15)
The system reports capacity utilization at startup: “Config feasible: 11 req/60s (73.3% capacity)“
hello world! I see you have a rate limit: 15 requests per 60 seconds ✓ Config feasible: 11 req/60s (73.3% capacity) ✓ Shared RateLimiter created (15 req/60s) ✓ Database: SQLite at data/market_data.db ✓ Started HIGH frequency tracking on (3 items) ✓ Started ARCHIVAL work + all known historical snapshots available right now on (1 items)GO TIME!
Start Conservative: Begin with longer polling intervals (30-60s) and gradually decrease as needed. This helps identify rate limit issues early.
Monitor Capacity: Aim for 70-80% capacity utilization. This provides headroom for startup bursts when all items fire simultaneously.
Startup Burst Warning: If you track more items than your rate limit, all items attempt to fetch data immediately at startup. The rate limiter will queue them, but expect initial delays.